Serveurs d’applications : IBM et BEA jouent la carte de l’interopérabilité

IBM et BEA Systems ont élaboré conjointement trois nouvelles spécifications qui visent à accroître l’interopérabilité de leurs serveurs d’applications J2EE ( Java 2 Platform Enterprise Edition) respectifs. Disponibles gratuitement, elles ont été publiées dans le but de recueillir les remarques des acteurs de ce domaine de l’informatique et de susciter leur adhésion. De l’aveu même des deux éditeurs, qui se disputent âprement la première place sur le marché des serveurs d’applications J2EE (voir édition du 7 mai 2003), ce projet répond à une demande de leurs clients, notamment les ISV (independent software vendors), qui souhaitent que leurs applications fonctionnent aussi bien sur l’une ou l’autre plate-forme. La principale spécification, appelée Service Data Objects, fournit un modèle de définition des données provenant de sources hétérogènes – bases de données relationnelles, XML, systèmes de gestion de contenu ou encore fournies par des applications adossées à une interface conforme aux standards des services Web, selon les principes de l’intégration en couplage lâche. Les deux autres, nommées Work Manager for Application Servers et Timer for Application Servers, servent à gérer l’exécution de tâches asynchrones.

Un standard pas si standard…

Au premier abord, cette initiative a de quoi étonner. En effet, le principal argument des environnements J2EE face à ?Net de Microsoft n’est-il pas précisément de s’appuyer sur un standard ? Or, par principe, un standard garantit qu’une application développée pour le serveur d’applications d’un fournisseur donné fonctionne aussi bien avec celui d’un autre, à la condition qu’il soit dûment estampillé J2EE. L’intérêt pour les entreprises est d’être, dans une certaine mesure, indépendantes de leur fournisseur, alors qu’il est de notoriété publique que celles qui choisissent les technologies Microsoft en sont captives. Or, le fait qu’IBM et BEA développent ces nouvelles spécifications est bien la preuve que l’interopérabilité entre serveurs d’applications J2EE est un avantage théorique. En vérité, J2EE ne constitue qu’un socle commun sur lequel chaque fournisseur ajoute des compléments de son cru, ce qui compromet l’interopérabilité. En bref, les serveurs d’applications J2EE sont plus propriétaires que ce que leurs promoteurs veulent bien avouer, et leurs clients moins indépendants que ce qu’ils pensent. Si les deux principaux vendeurs de serveurs d’applications J2EE font marche arrière et se mettent à jouer à fond la carte de l’interopérabilité, c’est probablement pour mieux lutter contre la concurrence de ?Net, pour mieux s’en différencier. De récentes études montrent en effet que la plate-forme de Microsoft gagne incontestablement du terrain sur J2EE (voir édition du 11 septembre 2003).

Sun marginalisé

Les spécifications en question ne devraient toutefois pas être intégrées dans les produits d’IBM et de BEA Systems avant un an, et ce bien qu’elles n’aient pas été au préalable officiellement promues au rang de standard Java. En effet, le processus de standardisation prend quelques années, ce qui représente à l’évidence un délai incompatible avec les attentes des entreprises. Notons au passage la marginalisation de Sun Microsystems et de Java Community Process, l’instance de standardisation mise en place par ce dernier. Tout laisse présager que les évolutions de Java seront à l’avenir prises en main par les deux plus gros fournisseurs de serveurs d’applications J2EE, au détriment de l’inventeur de la technologie Java et d’une concertation avec de plus petits acteurs. Cette méthode, qui repose sur le seul jeu des rapports de force, n’est pas sans évoquer le leadership exercé par IBM et Microsoft dans l’élaboration des standards des services Web, où les instances de standardisation comme l’OASIS ne jouent que le rôle de chambre d’enregistrement a posteriori (voir édition du 12 mai 2003).